Skip to content

Conversation

@davydog187
Copy link
Contributor

@davydog187 davydog187 commented Feb 9, 2026

Type-Safe Arithmetic & Comparisons

Goal

Proper Lua 5.3 arithmetic semantics with clear error messages.

Implementation

Float Division by Zero: Updated to approximate Lua 5.3 behavior:

  • positive / 0 returns 1.0e308 (approximating +inf)
  • negative / 0 returns -1.0e308 (approximating -inf)
  • 0 / 0 returns 0.0 (approximating NaN)

Note: True IEEE 754 infinity/NaN are difficult to create in Elixir/Erlang due to strict arithmetic checks. This is a documented limitation.

Arithmetic Type Checking (already complete):

  • All arithmetic operations use safe_* helpers with type checking
  • TypeError raised for non-numeric operands with clear messages
  • String-to-number coercion follows Lua 5.3 semantics

Comparison Safety (already complete):

  • == and ~= work on any types (return false for different types)
  • <, <=, >, >= only work on numbers or strings (same type)
  • TypeError raised for incompatible type comparisons
  • String comparison is lexicographic

Changes

  • lib/lua/vm/executor.ex - Updated safe_divide to handle division by zero
  • test/lua/vm/arithmetic_test.exs - Updated division by zero tests

Verification

  • mix format completed
  • mix compile --warnings-as-errors passes
  • mix test --exclude pending passes (1,011 tests)
  • All arithmetic type checking tests pass
  • All comparison safety tests pass

Improve float division by zero handling to approximate Lua 5.3 behavior.
Instead of raising errors, float division by zero now returns very large
numbers as approximations of infinity.

Changes:
- Update safe_divide to handle division by zero cases
- Positive / 0 returns 1.0e308 (approximating +inf)
- Negative / 0 returns -1.0e308 (approximating -inf)
- 0 / 0 returns 0.0 (approximating NaN)
- Update tests to reflect the approximation approach
- Document limitation vs true Lua 5.3 infinity/NaN support

Note: Elixir/Erlang's strict arithmetic makes true IEEE 754 infinity/NaN
difficult to create. This is a known limitation.

Arithmetic type checking (Phase 4A) was already complete:
- All arithmetic operations use safe_* helpers with type checking
- TypeError raised for non-numeric operands
- String-to-number coercion follows Lua semantics

Comparison safety (Phase 4C) was already complete:
- == and != work on any types
- <, <=, >, >= work on numbers or strings (same type)
- TypeError raised for incompatible type comparisons
- Lexicographic string comparison

All 1,011 tests passing.

Implements Phase 4 from plan.md
@davydog187
Copy link
Contributor Author

I'm not sure that we want to do this, I think we should potentially diverge from Lua 5.3 in this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant